r? @fmease

rustbot has assigned @fmease.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Failed to set assignee to mati865: invalid assignee

Note: Only org members with at least the repository "read" role, users with write permissions, or people who have commented on the PR may be assigned.

These commits modify compiler targets.
(See the Target Tier Policy.)

I don't see how crt-static would affect libunwind linkage with these changes. I think it would require special handling like here:

Also I think it might be the best to just build the unwinder during Rust build and always link it statically like here:

Ah, you're right, it looks like that only applies to Linux and Fuchsia targets.

I just clarified my commit message.

FWIW, here's a Dockerfile to reproduce this:

# Build with:
# docker build -t llvm-mingw .
FROM docker.io/mstorsjo/llvm-mingw:latest

# Supported architectures: x86_64, i686, aarch64 and armv7
ARG ARCH=x86_64

# Path settings
ENV RUSTUP_HOME="/usr/local/rustup" \
    CARGO_HOME="/usr/local/cargo" \
    PATH="/usr/local/cargo/bin:$PATH"

# Install curl
RUN apt-get update -qq && \
    apt-get install -qqy --no-install-recommends curl && \
    apt-get clean -y && \
    rm -rf /var/lib/apt/lists/*

# Install Rust
RUN curl https://sh.rustup.rs -sSf | sh -s -- -y \
      --no-modify-path \
      --profile minimal \
      --target $ARCH-pc-windows-gnullvm \
      --default-toolchain nightly \
      --component rust-src

WORKDIR /build

# Special flags for Rust
ENV CARGO_PROFILE_RELEASE_DEBUG=false \
    CARGO_PROFILE_RELEASE_CODEGEN_UNITS=1 \
    CARGO_PROFILE_RELEASE_INCREMENTAL=false \
    CARGO_PROFILE_RELEASE_LTO=true \
    CARGO_PROFILE_RELEASE_OPT_LEVEL=z \
    CARGO_PROFILE_RELEASE_PANIC=abort

RUN rm /opt/llvm-mingw/$ARCH-w64-mingw32/lib/libunwind.a

RUN cargo new foo --lib --vcs none && \
    cd foo && \
    echo "pub fn foo() {}" > src/lib.rs && \
    cargo rustc --release --crate-type=cdylib --target=$ARCH-pc-windows-gnullvm -Zbuild-std=std,panic_abort && \
    llvm-readobj --coff-imports target/$ARCH-pc-windows-gnullvm/release/foo.dll

Not my area of expertise
r? compiler

r? @petrochenkov
cc @mati865

The problem linking dynamic libunwind is the need of shipping libunwind together with the library/binary. I'll try if I can get crt-static feature to work or build libunwind together with std.

Ah, I see. LLVM just uses -lunwind, so it will link against the static libunwind.a variant when libunwind.dll{,.a} is not available.
https://github.com/llvm/llvm-project/blob/llvmorg-17.0.6/clang/lib/Driver/ToolChains/CommonArgs.cpp#L1829-L1831

If you pass -Clink-args=-static-libgcc, it will forcibly link against libunwind.a, but this is a bit odd from a Rust point of view. I'll close.

Opened #122003 that builds libunwind for these targets so we become independent of host toolchain when it comes to libunwind. Did some testing during Sunday and it seems to work fine but I'll try it with your Dockerfile using toolchain built the official way.